Verdict: COMMENT (would-be APPROVE)

Root-cause analysis is sound, fix is minimal and correctly scoped to the one site that needs it. Holding for James's stamp greenlight.

Root cause cross-checked against the issue's repro

Issue #1009 reports: 1080×1920 portrait video, position:absolute; inset:0; width:1080px; height:1920px, bottom 60-100px gap for the first ~37 seconds, macOS Chrome only, regression in v0.6.11 when enableBrowserPool: true became default. The new regression fixture (packages/producer/tests/portrait-video-fullbleed/src/index.html) matches the repro shape exactly. ✓

Tracing the fix:

• Pre-fix at screenshotService.ts:436-454: uses video.offsetLeft/offsetTop/offsetWidth/offsetHeight with getBoundingClientRect only as a fallback. The PR's claim that offset* can report stale compositor-dependent values on macOS Chrome under pooled browsers is plausible — these properties are computed from the rendering tree and can lag the CSS layout box when the compositor process is shared across workers and the video decoder is still settling.
• Post-fix: uses getBoundingClientRect() throughout. Returns CSS layout dimensions regardless of compositor state. Position computed as videoRect.left - parentRect.left to maintain the offsetParent-relative semantics the consumer expects.

The "fix at t≈37s" timing in the issue is consistent with the decoder-settles-then-offset-becomes-accurate theory.

Substantive observations

1. Linux CI can't reproduce the macOS-only bug — the regression fixture is a guard, not a proof.
   The portrait-video-fullbleed fixture renders correctly on Linux Chrome both pre-fix and post-fix because the offset*-divergence bug doesn't manifest there. So the fixture validates "the new code path produces correct geometry for portrait full-bleed video on Linux" (a useful regression guard), but doesn't prove the fix addresses the macOS-specific compositor issue. The actual validation has to happen by running the fix against the reporter's repo (dannymarx/hyperframes-issue-repo) on macOS. The PR's test plan already flags Needs macOS verification — this is the load-bearing pre-merge check. Worth waiting on before stamping.

2. Existing unit test doesn't exercise the divergence either.
   screenshotService.test.ts:113-130 mocks BOTH offsetLeft/Top/Width/Height AND getBoundingClientRect to return identical values (0,0,1920,1080), then asserts the resulting <img> style matches. With identical mocks, both code paths produce the same output → test passes pre-fix and post-fix. Acceptable for regression safety, but again not a fix-proof. Adding a test that mocks divergent values (offsetHeight: 1820, rect.height: 1920) would actually validate that the post-fix code prefers the rect. Optional.

3. offsetParent null fallback semantics changed.
   When video.offsetParent === null (e.g., position:fixed video, or a display:none ancestor), the post-fix code falls back to { left: 0, top: 0 } for the parent rect, making the replacement <img> viewport-positioned. Pre-fix, offsetLeft/Top also returned 0 in this case (per spec — null offsetParent collapses offsets to 0), so the <img> landed at (0,0). For position:fixed video, post-fix is more correct (matches the video's actual viewport position); for hidden video, neither matters. Mostly an improvement, but a real behavior change worth being aware of.

4. Transform inclusion is a behavior change too.
   getBoundingClientRect includes CSS transforms; offsetWidth/Height does not. If a composition applies transform: scale(0.5) to a <video>, pre-fix gave the un-transformed layout box (1080×1920 for the issue's video), post-fix gives the rendered size (540×960). For replacement-frame rendering, post-fix is more correct — we want the replacement to occupy the rendered space, not the un-transformed layout box. Worth a quick mental check on whether any hyperframes patterns scale <video> elements; grep didn't surface any, so this is probably theoretical.

5. Math.round is the right call but introduces sub-pixel rounding.
   offsetWidth is integer by spec; Math.round(rect.width) could round 1919.4 → 1919, leaving a 1px gap at the bottom. The bug being reported is 60-100px, so this isn't the cause. But on high-DPR macOS displays where sub-pixel layout is common, this could surface as a faint 1px artifact on different compositions. Minor. Math.ceil for width/height would be slightly more conservative; doesn't matter for the reported bug.

Sanity checks

• Parity check: grepped packages/engine/src/services/, packages/producer/src/, and packages/core/src/ for any other site that uses video.offsetWidth/offsetHeight for replacement geometry. screenshotService.ts is the only consumer. No parallel paths to update. ✓
• CI: 15 success / 2 in_progress / 13 cancelled (all the cancelled are superseded reruns of greens). No real failures.
• Mergeable_state: blocked — waiting on reviews/checks.

Pre-merge ask

The most important verification isn't in this PR — it's running the fix against the reporter's repro on macOS. The fix is theoretically sound and the regression fixture catches future drift on the Linux path, but only a macOS run proves the bug is actually closed. Once Miguel (or someone with a macOS box) confirms the reporter's out.mp4 no longer has the bottom gap, stamp-ready.

— Rames Jusso